there is a typo in example object under
"However, with the LightMethodProtocol, a client could instead post to"
and i think it is better to create ControllerLight instead of trait

I added a commit to fix the typos.

My first instinct of the addition was in fact a LightController subclass of Controller instead of a Trait. Here is why I thought it might be better as a Trait:

I have several additions in mind for the library: the Auth extension (already merged), this LightMethodProtocol option (in this pull request), a FormPostProtocol option (currently a work-in-progress), and I imagine we may come across other extensions (https://jsonrpcx.org/Main/HomePage) or options we may want to consider further down the road.

Implementing each extension/option as a subclass of Controller does make it easier for a developer to use since they only need to extend the right subclass of Controller, but it makes it harder to mix and match multiple options unless we provide a subclass of Controller for each combination of options.

However, by implementing the options as Traits, a developer could do the following:

class ServicesController extends \JsonRpc2\Controller
{
    use \JsonRpc2\LightMethodProtocolTrait;
    use \JsonRpc2\extensions\AuthTrait;
    use \JsonRpc2\FormPostProtocolTrait;
    use \JsonRpc2\FutureOptionalProtocolTrait;
    use \JsonRpc2\extensions\StatusTrait;
    use \JsonRpc2\extensions\ControlTrait;
}

and easily enable or disable individual options/extensions like:

class ServicesController extends \JsonRpc2\Controller
{
    use \JsonRpc2\LightMethodProtocolTrait;
    //use \JsonRpc2\extensions\AuthTrait;
    //use \JsonRpc2\FormPostProtocolTrait;
    use \JsonRpc2\SomeFutureOptionalProtocolTrait;
    //use \JsonRpc2\extensions\StatusTrait;
    use \JsonRpc2\extensions\ControlTrait;
}

As the number of options/extensions grows in the future, I believe this is a more elegant solution than creating a Controller subclass for each scenario.

It might be worth considering implementing both options to some extent. In addition to the traits, we could provide a couple of Controller subclasses for developer convenience, like

namespace JsonRpc2;
class ControllerExtended extends \JsonRpc2\Controller
{
    use \JsonRpc2\LightMethodProtocolTrait;
    use \JsonRpc2\extensions\AuthTrait;
    use \JsonRpc2\FormPostProtocolTrait;
    use \JsonRpc2\FutureOptionalProtocolTrait;
    use \JsonRpc2\extensions\StatusTrait;
    use \JsonRpc2\extensions\ControlTrait;
}

class ControllerLight extends \JsonRpc2\Controller
{
    use \JsonRpc2\LightMethodProtocolTrait;
}

This way, a developer could use one of the default Controller instances, but also have the option of using individual Traits to mix and match as needed for their particular application.